Code Complete Lessons Learned
General Considerationsโ
- Design is part of the software engineering process
- Also need to cater for how the engineers will review their code and how quality assurance will be ensured.
- Need to know if we are doing a blackbox testing, integration testing, unit testing etc
- Data Design - how is data organised
- Database - key restraints, key value no cache, sql nosql
- Files organised
- Single data storage or multiple storage
- High Fan In - determines how many classes uses utils/constants. Signifies if classes are reusableย
Security Considerations
- Authentication for API - JWT, cookies, passwords, encryption
- Data input/output
- Scalability
- Internationalisation - should it be an issue
- Buy vs Build Decisions
- Error Processing - how is error codes organised (https://stripe.com/docs/api/errors)
Wicked Problem (Horst Rittel and Melvin Webber 1973)โ
- Problem needs to be solved at least once or part of it, and then solve it again for a more stable solution
- Case Study: Tacoma Narrows Bridge - a suspended bridge, where the engineers only catered for how heavy the bridge should be able to handle, but did not cater for the air
- Heuristic Approach - a.k.a Trial and Error approach
Levels of Design
Software Systemโ
- Total Architecture of the system
Division of Subsystem/packagesโ
- We need to specify how each subsystem will interact with each other, otherwise spaghetti interaction will ensure sooner or later
- For Example: Business Logic starts depending on GUI
- Establish communications rules for each subsystem
- User Interface
- Application Level Classes/Business Logic
- Data Storage
- Graphics
- Enterprise Level Tools
- for example, if you are doing windows dependent system, you need to seperate logic for it. Down the line you might need to change to OS, Linux
- Division into classes within packages
- Division into data and routines
- Interfaces, private classes ย etc
Internal Routine designโ
This is what usually programmers do everyday. This is done routinely consciously or not. Below are the things to consider.
- Binding Time - binding specifies when a value is set to a variable
- Coding time (magic numbers)
- Compile time (constant)
- Run time (just in time, use of a method to fetch on run time)
- Live time - variable declared vs when it is used
- Learn to use abstract data types
- There are different ways to handle errorsย
- Global exception handling
- Handle locally as much as possible
- Declare only exception if calling method needs to know the error - this breaks encapsulation
- Return neutral values, ie, 0, โโ, null, etc
- Exception handling differs in different system see below (Robustness vs Correctness
Robustness vs Correctnessโ
- if you are working on data critical system, i.e medicinal software, better the system shutdowns when an error occurs rather than returning incorrect values
Learnings
- A number of developers has been tested to prioritize: speed, readability, memory allocation, least code, time. And they all scored number one on what they prioritized. Programmers do what they are told to focus on.ย
- Unit testing is never enough, one form of testing alone leaves the code brittle. It is a combination of tests that ensure quality
- Logic tests are tests that check and variations in the logic. Every if for else any control flow.ย
- No one testing method is enough.ย
- Keep a testing/error database record to assess the health of your application Scientific way of debugging. Dont just guess. Give brute force trying a definite limit
- Make sure you put in architect that is well respected to set the standards rather than a non technical person
Anti-Patterns
Hybrid Coupling - when a variable has more than one use.
- Example:
pageCount
will be set to -1 if a error occurs
- Example:
Recursion is overrated, Stack space is limited andย is quite slow
Table driven methods, direct table access like a month lookup, or insurance rate tables
- No Encapsulation, any change will immediately break code
Complexity can be determined by the number of decision points in a method. If or then and are all decision points
Data logic tests initializations of data in the the code.ย
"Dont document bad code rewrite it" Kernighan 1978
Brooks law 1975 (more people != more progress)
- more people does not mean more progress. 9 women cant make a baby in a month